1. Field of the Invention
The present invention relates to a communications device that performs encrypted communications. More particularly, the present invention relates to a communications device used in an environment, such as a home network, to perform automatic key exchange.
2. Background Information
RFC 2401 through RFC 2412 (RFC: Request for Comments) formulated by the IETF (Internet Engineering Task Force) stipulate the IP security (IPsec) protocol and the IKE (Internet Key Exchange) key exchange protocol. IPsec is a protocol within IP (Internet Protocol) that authenticates encrypted communications and IP packets. Unless otherwise noted below, the term “encrypted communications” does not exclude functions which authenticate communications data.
Communications gateways and communications terminals (hereinbelow, collectively referred to as communications devices) having built-in encryption functions based on IPsec perform encrypted communications over a logical communications path called a security association (SA). In a security association, the key data (encryption key and authentication key) used by the encrypted communications, the applicable encryption algorithm data, the authentication algorithm data, and the like, are managed. In particular, the security association (encrypted communications path) used by IPsec based encrypted communications is called an IPsec SA.
An example of a method that establishes an IPsec SA between communications devices performing encrypted communications is manual key setting, in which various IPsec SA data is manually set in both communication devices. In addition, there is also automatic key exchange (IKE), wherein both communication devices mutually confirm whether the other can properly perform encrypted communications, and then both negotiate and determine various IPsec SA data to establish an IPsec SA. IKE is particularly defined in RFC 2407 through RFC 2409. In IKE, negotiation is performed to establish an IPsec SA. A control communications path for performing this negotiation is called an ISAKMP SA. This ISAKMP SA is not only for establishing the IPsec SA, but is also used for updating the IPsec SA and deleting the IPsec SA data. Furthermore, ISAKMP is an abbreviation for Internet Security Association and Key Management Protocol, which is the title that stipulates the IKE communications protocol.
FIG. 12 depicts an example of a network configuration that applies an encrypted communications system. In the encrypted communications system of FIG. 12, a terminal 101, for example, communicates with a terminal 103 via a gateway 111, a communications network 121, and a gateway 112. An example of an embodiment that performs encrypted communications is one that establishes a comprehensive encrypted communications path (security association, hereinafter referred to as SA) between two parties of the gateway 111 and the gateway 112, and encrypts communications via both parties between both gateways. In addition, there is another embodiment that performs encrypted communications by establishing a direct SA between two parties among terminals 101-104. Furthermore, there is an embodiment that combines the former and the latter, wherein, for example, if the terminal 101 communicates with the terminal 103, then encrypted communications is performed by establishing an SA between the terminal 101 and the gateway 112. Hereinafter, gateways and terminals that establish an SA are simply referred to as communications devices.
FIG. 13 is an explanatory diagram that depicts the state of an SA for performing encrypted communications (IPsec communications) based on IPsec using IKE between the communications devices. A communications device 201 in FIG. 13 is one of the terminals 101-102 or the gateway 111 in FIG. 12. A communications device 202 is one of the terminals 103-104 or the gateway 112 in FIG. 12. In FIG. 13, an ISAKMP SA 211 is used for the establishment, updating, and disconnection of an IPsec SA 212. Furthermore, in IPsec communications, SA data is managed by the direction of that communication. If IKE is used, then there are two types of SA data managed by each communications device for establishing the IPsec SA that implements bidirectional communications: for input and for output. However, bidirectional communications is presupposed herein, and these are illustrated as one bundled IPsec SA.
IKE uses IP packet communication, which uses a message format called an ISAKMP message to establish the ISAKMP SA and to establish the IPsec SA. To establish an ISAKMP SA, there is, for example, a negotiating means (transaction) called Main Mode. To establish an IPsec SA, there is, for example, a negotiating means called Quick Mode. Basically, the negotiating means for updating an IPsec SA and an ISAKMP SA are similar to the establishment negotiating means. In addition, IKE stipulates an ISAKMP message for the purpose of notifying the various types of data outside of the negotiating means for establishing an SA. Among these, Delete and Notify messages are also defined for ISAKMP SAs and IPsec SAs.
Encrypted communications are principally used for assuring the confidentiality and integrity of communicated data, but a key is needed for encryption and decryption. If this key is made known to a third party, then the third party can easily decrypt that encrypted data. Consequently, the management of the key is important. A key can be inferred from the encrypted data if time and effort are applied; furthermore, it becomes all the more easier to infer the key if a large amount of data encrypted using that key is collected. Consequently, a mechanism is provided in IKE to newly establish an IPsec SA principally for updating key data. This is called IPsec SA updating. An IPsec SA lifetime is determined when establishing an IPsec SA, and the IPsec SA is updated according to that lifetime. Examples of the timing of IPsec SA updating include a method that performs updating after the IPsec SA lifetime has expired, and a method that performs updating at a predetermined timing prior to the expiration of the lifetime. The latter method is superior for the continuity of encrypted communications, and is the more commonplace method. An ISAKMP SA that is the control communications path is needed to update an IPsec SA. FIG. 14 depicts a situation in which a new IPsec SA is established for updating by a method that performs updating prior to the expiration of the lifetime. An IPsec SA 311 is the IPsec SA newly established for updating.
The disconnection of an IPsec SA occurs principally by the expiration of its lifetime. In FIG. 14, the IPsec SA 212 is in a state in which it has already been updated by the IPsec SA 311, and its lifetime is about to run out. When the lifetime runs out, the IPsec SA 212 is disconnected, and its old IPsec SA data is deleted from the communications devices 201, 202. It is preferable that the lifetime length be determined by the algorithm that uses that key, the purpose of the encrypted communications, and the like; nonetheless, there is also a mode that uses a predetermined value. Another method that disconnects the IPsec SA is one that deletes the IPsec SA data in one communications device, and also deletes the corresponding IPsec SA data in the other communications device by notifying this other communications device of that deletion. This method is useful if the application that operates one communications device, or its user, expressly instructs disconnection. An ISAKMP SA is generally used to transmit and receive an IPsec SA Delete Notify. Note that a Delete Notify is defined as a Notify message (Informational Exchange), which includes a Delete Payload, in the ISAKMP message.
However, the ISAKMP SA also carries out communication of encrypted data, and has its own lifetime. Accordingly, the IPsec SA cannot be established, updated, or disconnected unless the ISAKMP SA is updated. However, in the abovementioned RFC, a method of maintaining the ISAKMP SA is not strictly defined, and a plurality of implementation methods are conceivable. For example, there is a method that also updates the ISAKMP SA, and there is a method that establishes a new ISAKMP SA when it becomes necessary without updating the ISAKMP SA. Furthermore, if there is also an implementation method for transmitting and receiving the Delete Notify that requests the usage of the ISAKMP SA that was used to establish the IPsec SA to be deleted, then there is also an implementation method that, if there is a plurality of ISAKMP SAs, always uses the newest ISAKMP SA.
In IPsec based encrypted communications, encrypted communications is achieved by the communications devices retaining SA data related to the IPsec SA, as discussed above. Incidentally, a situation may arise in which only one of the communications devices has the SA data, but the corresponding SA data does not exist in the other communications device, i.e., a state in which there is an inconsistency in the IPsec SA. In this situation, an attempt is made to carry out encrypted communications from the communications device retaining the SA data by using the already retained SA data of the IPsec SA, and the corresponding packet is thereby encrypted and transmitted. In contrast, because the corresponding IPsec SA is retained by the other communications device, this packet is unfortunately discarded, and encrypted communications is not established. To recover from this communications failure state, it is necessary to undergo a procedure, such as: 1) delete the IPsec SA retained by one of the communications devices; 2) the application expressly instructs IKE to establish a new IPsec SA; and 3) the lifetime of the IPsec SA runs out.
In relation to this type of problem, consider a situation in which the two communications devices are gateways, and communications is carried out between two terminals via two gateways. In this situation, if the IP address of one of the gateways is modified, then, attendant with that modification, an inconsistency arises in the ISAKMP SA and the EPsec SA data. To resolve this inconsistency, Japanese Published Patent Application No. 2002-344443 therefore proposes a method that includes the following three steps:    1) transmit an ISAKMP SA Delete Notify to the other gateway,    2) the other gateway that receives that Delete Notify disconnects the IPsec SA previously established by the ISAKMP SA to be disconnected, and    3) subsequently, establish a new ISAKMP SA and an IPsec SA between the gateways.
With this method, in situations where the IP address has been modified by a power supply restart and the like, an ISAKMP SA Delete Notify is transmitted to the other gateway using a premodification identifier, e.g., the IP address before the modification.
However, in the method recited in Japanese Published Patent Application No. 2002-344443, there is a problem in that the inconsistency of the IPsec SA that arises cannot be resolved if the IPsec SA has been expressly disconnected in one communications device because it is operating in the event of a power supply restart or an IP address modification.
Furthermore, if encrypted communications is achieved between communications devices, then there is a portion that is implementation dependent in the method that retains the ISAKMP SA, as discussed above. Consequently, if encrypted communications is attempted using IKE between communications devices having mutually different implementation modes, then an IPsec SA Delete Notify is not necessarily transmitted under conditions in which the other communication device receives it correctly. The result is that IPsec SA disconnect processing cannot necessarily be performed reliably, and it is possible that an inconsistency in an IPsec SA will arise.
In such a situation, IPsec SA establishment can be performed again by making the IPsec SA in which an inconsistency has arisen have a lifetime that expires. In addition, IPsec SA establishment can be performed again by confirming that encrypted communications has not been established after the application or its user has waited a prescribed interval of time, and then expressly deleting the retained IPsec SA. However, in either situation, there is a problem in that time is needed from when IPsec SA disconnect processing is performed incompletely until IPsec SA establishment restarts.
The present invention solves the aforementioned problems, and provides a technology that, with the various types of implementation modes for maintaining an ISAKMP SA, prevents the arising of an inconsistent state in an IPsec SA by reliably transmitting and receiving an IPsec SA Delete Notify mutually between communications devices.